Folge 4: Developer Experience bei JobRad®

00:00:00: Ich war vor einigen Jahren mal im Fitnessstudio.

00:00:02: Inzwischen gehe ich da nicht mehr hin, aber das hat andere Gründe.

00:00:05: Und dann habe ich versucht, meinem damaligen Trainer,

00:00:08: während ich schwitzend auf der Bank lag, zu erklären,

00:00:10: was ich eigentlich beruflich mache.

00:00:12: Und dann habe ich in zehn Minuten zugeschwafelt,

00:00:14: so wie jetzt gerade eben dich auch.

00:00:16: Und am Ende hat er so genickt und meinte,

00:00:17: ah ja, du machst das, das flutscht.

00:00:19: Increase Cycle Time, der Jobrat Development Podcast.

00:00:31: Hallo, liebes Internet.

00:00:32: Herzlich willkommen zu einer neuen Folge Increase Cycle Time.

00:00:35: Das ist der Software Development Podcast von Jobrat.

00:00:38: Ich bin Holger, ich bin Software Engineer bei Jobrat.

00:00:42: Ich arbeite in einem Produktteam, der PTO.

00:00:45: PTO, das ist die Product and Tech Organisation hier bei Jobrat.

00:00:48: Und ich mache das nicht alleine.

00:00:50: Ich sitze hier mit meinem geschätzten Kollegen Urs.

00:00:52: Hallo, liebes Internet, ich bin Urs.

00:00:55: Ich leite das Team Developer Experience in der PTO.

00:00:59: Wir möchten euch mal zu zweit und mal mit Gästen

00:01:02: das Thema Softwareentwicklung bei Jobrat

00:01:05: in all seinen Facetten näher bringen.

00:01:07: Und jetzt wünschen wir euch viel Spaß mit der neuen Folge.

00:01:10: Hallo, liebes Fahrradaffines Internet.

00:01:14: Diesmal haben wir ein Thema direkt vorbereitet,

00:01:19: über das ich sehr, sehr viel sagen kann,

00:01:22: weil ich selber daran beteiligt bin und davon betroffen bin.

00:01:25: Das Thema ist Developer Experience

00:01:28: und was macht Jobrat im Kontext Developer Experience?

00:01:34: Hallo, Holger.

00:01:36: Hallo, ich bin auch da.

00:01:37: Aber du hast Folien vorbereitet.

00:01:40: Ich hab Folien vorbereitet, das zeig ich euch jetzt.

00:01:43: Man hört das Rascheln der Overhead-Folien.

00:01:47: Bei einem Hintergrund wäre du gleichzeitig schreibst und wischt.

00:01:50: Ja, nee, wir haben die...

00:01:53: Wir haben in jeder Folge das mal angekratzt

00:01:56: in deiner Rolle bei Jobrat.

00:01:58: Bist du ja im Bereich Developer Experience tätig?

00:02:02: Das ist jetzt eine...

00:02:03: Ja, weiß ich nicht, das ist mir in meiner Vergangenheit

00:02:08: schon des öfteren Begegnets in diversen Funktionen.

00:02:12: Aber letztendlich ist es immer an jeder Stelle

00:02:14: mehr so ein bisschen anders und von daher war...

00:02:15: Was ist für mich so die eine der ersten Fragen?

00:02:18: Na ja, Developer Experience, was ist das denn?

00:02:21: Was ist das für dich? Was ist das für Jobrat?

00:02:24: Und was hängt da für dich mit dran?

00:02:26: Hast du erst gesagt, kann ich eigentlich gar nichts zu erzählen?

00:02:29: Außer vielleicht diese 20 Punkte.

00:02:31: Und mal gucken, ob wir bis Folge Punkt 3 hier in dieser Folge kommen.

00:02:38: In unserer selbstgesteckten Zeit-Begrenzung.

00:02:42: Wenn du Lust hast, können wir mal ein Experiment machen.

00:02:45: Was ist denn für dich, Developer Experience?

00:02:47: Nee, das funktioniert nicht.

00:02:48: Also, bald zurückspielen, das geht nicht.

00:02:49: Spiegelkarte. Spiegelkarte.

00:02:51: Spiegelkarte geht nicht.

00:02:52: Nee, fände ich aber spannend tatsächlich,

00:02:54: weil ich eigentlich immer dieselben Sätze sage.

00:02:58: Und also, dadurch werden sich meine Sätze wahrscheinlich,

00:03:01: das ist hier gerade jemand, umgefallen,

00:03:03: werden sich meine Sätze nicht verändern,

00:03:05: wenn du jetzt was anderes sagst, aber...

00:03:08: Nee, aber was ist für mich...

00:03:09: Ich bin jetzt natürlich... Leute, bear with me,

00:03:11: ich bin unvorbereitet, was ist das für mich Developer Experience?

00:03:14: Was erwartest du, wenn du das hörst?

00:03:16: Nee, ich glaube, die einfachste Definition für mich ist,

00:03:19: es gibt ja sowas wie User Experience.

00:03:22: Und User Experience als die, na ja, die...

00:03:29: Das ist eine Eigenschaft, wie ich sage jetzt mal,

00:03:32: eine Eigenschaft an eine Anwendung oder an ein Ding

00:03:35: oder an eine Problemlösung,

00:03:37: die es dem Nutzenden möglichst angenehm macht

00:03:44: oder möglichst effizient macht,

00:03:45: das Problem mit irgendetwas zu lösen.

00:03:48: Keine Ahnung, der...

00:03:51: Der Stefan, mit dem ich dann gerne beim Thema User Experience zu tun habe,

00:03:55: gibt da immer nur das Beispiel des Eierkochers.

00:04:00: Also es gibt so eine, so kennst du möglicherweise,

00:04:03: das ist ein Eierkocher, den du in den Kühlschrank packst,

00:04:08: gleiche Temperatur wie die Eier, und der macht dann irgendwie,

00:04:10: packst du dann mit den Eiern in den Kochtopf rein.

00:04:16: Und der macht dann zu bestimmten Temperaturen,

00:04:18: macht er dann halt zu Zeiten, nicht zu Temperaturen,

00:04:22: macht er dann irgendwelche, spielter Melodien ab.

00:04:25: Und das löst das Problem, na ja, ich möchte, keine Ahnung,

00:04:29: ich möchte ein schönes Runny, Runny-Eck haben.

00:04:32: Und man kann sich vorstellen,

00:04:35: während, ich weiß gar nicht, ob das wirklich passiert ist,

00:04:38: während der Entwicklung dieses Produktes hat man sich hingestellt

00:04:42: und hat gesagt, na ja, ich brauche eine App,

00:04:44: ich muss irgendwie Probes in mein Ei setzen,

00:04:47: damit das möglichst genau, und du kannst dir vorstellen,

00:04:49: wo das hingeht, nee, ich löte das Problem einfach anders.

00:04:53: Und Long Story Short, genau das stelle ich mir

00:04:55: für Developer Experience vor.

00:04:57: Ich habe irgendein Problem und möchte da irgendein Anpack haben,

00:05:02: das zu lösen, also vielleicht irgendein Pain Points.

00:05:05: Vielleicht habe ich, was habe ich jetzt,

00:05:12: ich habe jetzt nur Beispiele, die dir jetzt schon viel drauf vorgreifen.

00:05:16: Wir haben gerade schon über Dora Meter geredet,

00:05:18: da will ich jetzt gar nicht kurz alles damit drüber reden.

00:05:20: Aber Developer Experience heißt, ich habe Tools,

00:05:24: die auf die Bedürfnisse von Entwicklungsmenschen

00:05:29: schon hinzielen.

00:05:32: Ich habe vielleicht Kommando-Zeilen-Tools,

00:05:34: ich habe vielleicht, weiß ich nicht, gute Keyworten,

00:05:39: Navigatability, ja, Punkt.

00:05:43: Ich finde es total spannend, was du sagst,

00:05:45: weil, als ich zu Jobrat kam,

00:05:50: habe ich mit meinem Vorgesetzten, dem Jan,

00:05:53: die Diskussion gehabt, wie nennen wir jetzt eigentlich das Team,

00:05:55: nennen wir das jetzt Developer Productivity,

00:05:57: und dann nennen wir das Developer Experience.

00:06:01: Und mein Punkt war,

00:06:04: wir wollen eigentlich eine positive Message transportieren,

00:06:09: und wir wollen quasi sagen,

00:06:11: wir wollen, dass Entwicklende bei Jobrat,

00:06:15: ich sage mal bewusst Flapsig, eine gute Zeit haben.

00:06:20: Die andere Perspektive, Developer Productivity,

00:06:22: wäre jetzt ja eher die unternehmerische Perspektive,

00:06:24: also wir wollen, wenn hier schon Leute die ganze Zeit

00:06:27: an Software arbeiten, dass sie das auch möglichst effizient

00:06:30: und effektiv tun.

00:06:32: Das wollen wir zwar auch natürlich, aber wir gehen davon aus,

00:06:35: dass das so ein selbst motiviertes Ding ist.

00:06:38: Also wenn jemand das Gefühl hat,

00:06:40: dass er effizient und effektiv ist,

00:06:42: dann ist er wahrscheinlich auch zufrieden.

00:06:45: Und ja, so kam es zu diesem Namen.

00:06:48: Und meine Aussage ist eigentlich immer, wenn mich jemand fragt,

00:06:50: was machst du denn, Developer Experience, sage ich immer,

00:06:53: Developer Experience ist erstmal alles,

00:06:55: was so eine Entwicklerin oder ein Entwickler

00:06:58: in ihrem Alltag erlebt.

00:07:00: Das ist die Experience, die ein Entwickler hat,

00:07:03: ich sage jetzt mal bewusst nur noch Entwickler,

00:07:05: um das kürzer zu halten.

00:07:07: Und jetzt ist die nächste Frage für ein Unternehmen,

00:07:13: jetzt haben meine Entwicklenden ja irgendeine Experience,

00:07:16: aber wie ist die denn?

00:07:18: Ist die jetzt gut, ist die schlecht, wenn sie nicht gut ist,

00:07:20: was müssen wir tun, damit es besser wird?

00:07:22: Das heißt, das Ganze dreht sich sehr schnell um Metriken.

00:07:24: Wir müssen erstmal irgendwie die Developer Experience,

00:07:27: die so die Fuß im Raum steht, sichtbar machen.

00:07:29: Und das ist so zumindest ein großer Teil meiner Arbeit,

00:07:36: diese Dinge sichtbar zu machen über unterschiedliche Metriken

00:07:39: in der Regel, indem ich einfach Leute befrage,

00:07:42: natürlich nicht willkürlich, sondern organisiert über Metriken,

00:07:45: wie gesagt, oder indem ich Systeme befrage.

00:07:49: Also ich kann ja auch aus dem Verhalten von Systemen

00:07:52: irgendwie Rückschlüsse ziehen.

00:07:54: Und so ergibt sich dann halt dieses Bild.

00:07:55: Und dann ergeben sich ja auch Handlungsfelder, sage ich jetzt mal.

00:08:01: Normalerweise ist das aber auch gerade in nicht total durchoptimierten

00:08:08: Unternehmen relativ klar, welche Mancos man hat.

00:08:12: Und das Schöne ist dann aber, dass man es mit Daten

00:08:14: unterfüttern kann und Daten informiert arbeiten kann.

00:08:17: Das heißt, du sagst nicht nur, irgendwie haben wir ein Qualitätsproblem,

00:08:21: zum Beispiel, sondern du kannst dann relativ genau festmachen,

00:08:24: wir haben eine Testcoverage von N und wir hätten gerne N+X

00:08:29: und daraufhin Arbeit.

00:08:30: Aber das ist auch schon eine kontroverse Aussage ist, aber auf Testcoverage.

00:08:35: Auf Testcoverage zu gamifizieren, aber das ist ...

00:08:39: Nee, das war jetzt gar nicht gamifiziert gemeint.

00:08:41: Das war jetzt mehr so aus dieser Managementperspektive.

00:08:43: Also irgendwie musst du es ja messen.

00:08:45: Und du hast einfach dann zumindest mal eine Zahl, die du dranschreiben kannst

00:08:49: und kannst dir überlegen, wo du hinkommen willst

00:08:51: und kannst dann irgendwie zielgerichtet Maßnahmen machen.

00:08:53: Also es geht gar nicht drum, dass du jetzt den Leuten sagst,

00:08:55: ich möchte aber bitte, dass bis nächstes Jahr da nicht mehr 50%,

00:08:58: sondern 70% steht, sondern es geht darum,

00:09:00: dass du überhaupt mal weißt, wo du steht.

00:09:02: Nein, das steht, das ist möglicherweise auch für eine der nächsten Folgen

00:09:06: ein spannendes Thema.

00:09:07: Ja, also das sind wir ganz schnell bei "Good Hearts Law" und so.

00:09:11: Nee, es ging jetzt auch gar nicht drum,

00:09:15: ob Testcoverage eine tolle Metrik ist, um Qualität sicherzustellen.

00:09:21: Aber Beispiel, soweit abgeschlossen und verstanden,

00:09:25: also es ist gut, wenn du Zahlen an Empfindungen ranschreiben kannst.

00:09:29: Und es ist natürlich besser, wenn du das Gefühl hast,

00:09:33: dass es genau die richtigen Zahlen gibt.

00:09:36: Du hast, ja, du hast "Developer Productivity Engineering" schon erwähnt.

00:09:42: Ich bewege mich da jetzt auf dünnem Eis,

00:09:43: weil der Mensch, mit dem ich so einen anderen Podcast mache,

00:09:46: der nennt sich Developer Productivity Engineer

00:09:49: und hat das bei einer Firma gemacht,

00:09:50: die sich "Developer Productivity" verschrieben hat.

00:09:53: Von daher werde ich möglicherweise

00:09:55: wirklich Aussage in dieser Folge dreifach und vierfache

00:09:58: in der Nase und sonst wie rumgedreht kriegen.

00:10:02: Das ist aber egal. Wo siehst du für dich die ...

00:10:06: Also ich sehe gerade zwei verschiedene Schnittstellen,

00:10:09: also Schnittnängen, Schnittstellen.

00:10:11: "Developer Productivity Engineering" und zum "Platform Engineering".

00:10:15: Da bist du ja irgendwie auch in der Nähe von,

00:10:17: dass du, du kennst dieses Spotify-Plat ...

00:10:21: Ich hab's den Namen jetzt vergessen, aber das geht ja auch in die ...

00:10:25: "Backstage" meine ich, genau. Das geht ja auch in die ähnliche Richtung.

00:10:29: Tut es das?

00:10:31: Also "Backstage" ist ja ein Plattformportal.

00:10:36: Und das ist gerade auch so ein bisschen Hype in der Szene.

00:10:41: Hätte ich gesagt, das ist schon drüber.

00:10:44: Ja, immer noch andauernd, genau.

00:10:50: Aber "Backstage" löst ja schon ein relativ konkretes Problem.

00:10:55: Also nicht mehr so ein allgemeines Productivity-Ding.

00:10:58: Also deine Frage war, wo knüpft das an?

00:11:01: Ich glaube, dass die Schnittmenge zumindest mal zwischen

00:11:05: "Developer Productivity Engineering" und "Developer Experience"

00:11:09: sehr, sehr groß ist.

00:11:11: Das ist eigentlich einfach eine andere Perspektive auf dasselbe Problem.

00:11:15: Hätte ich fast auf dem Model.

00:11:16: Der Begriff "Developer Productivity Engineering"

00:11:19: ist sehr stark geprägt von Gradle.

00:11:22: Weil, na ja, die das eben für ihr Marketing ...

00:11:26: Von Marketingbegriff, genau, ja.

00:11:28: Sehr stark ausschlachten.

00:11:30: Da gibt es ja auch die Konferenz, DPE Summit und so weiter.

00:11:36: Das ist aber was Gutes, glaube ich, dass das Unternehmen gibt,

00:11:39: die sich um dieses Thema kümmern und das ein bisschen vorantreiben.

00:11:42: Und natürlich machen die das nicht selbstlos,

00:11:45: so wie wahrscheinlich kein Unternehmen irgendwas völlig selbstlos tut.

00:11:49: Aber sie machen es zumindest so, dass andere Unternehmen davon auch profitieren.

00:11:53: Deswegen bin ich da dankbar für.

00:11:55: Wo sich es vielleicht unterscheidet ist,

00:12:00: wenn ich sage, ich mache "Developer Productivity Engineering",

00:12:06: das hatte ich ja vorhin schon mal angedeutet,

00:12:08: dann optimiere ich vor allem einen Teilbereich der "Developer Experience".

00:12:13: Nämlich die Produktivität.

00:12:16: Und dafür dann andere Teilbereiche,

00:12:19: die vielleicht "Developer Experience" nicht abdeckt.

00:12:22: Also, vielleicht kann man das so zusammenfassen,

00:12:25: dass man das gleiche Thema bearbeitet,

00:12:28: aber mit einer anderen Zielformulierung.

00:12:31: Die kann unter Umständen ähnliche Outcomes haben,

00:12:34: aber es sind halt unterschiedliche Outcomes im Fokus.

00:12:37: Verstehe. Verstehe.

00:12:39: Und zum Thema "Plattform Engineering" bei uns,

00:12:45: und ich denke auch bei vielen anderen Unternehmen,

00:12:47: ist das Team "Developer Experience",

00:12:49: also, sofern das andere Unternehmen so ein Team auch hat,

00:12:52: Teil des Plattformbereichs, also jetzt in "Team Topologies" denke,

00:12:59: und beschäftigt sich zum Teil auch mit "Plattform Engineering".

00:13:04: Also, wir wollen unseren Entwicklenden unter anderem eine Plattform anbieten,

00:13:08: auf der Software entwickelt werden kann,

00:13:10: und wo ich mag diese Formulierung sehr, wo "Cognitive Load" abstrahiert wird.

00:13:17: Also, du kannst "Cognitive Load" nicht entfernen.

00:13:19: Komplexe Probleme bleiben komplex,

00:13:23: aber du kannst die Komplexität abstrahieren und zentralisiert lösen,

00:13:27: z.B. in so einem Dev-Ex-Team.

00:13:30: Und wenn es darum geht, z.B. ein Kubernetes-Deployment zu machen,

00:13:35: das an sich erst mal eine komplexe Sache ist,

00:13:37: dann kannst du das für den einzelnen Anwender weniger komplex machen,

00:13:41: indem du in irgendeine Standardlösung bereitstellst,

00:13:44: dann abstrahierst du es weg und löst es in diesem Dev-Ex-Plattform-Team.

00:13:48: Ja, verstehe.

00:13:49: Und das ist jetzt natürlich einfach eine Frage deiner Organisationsarchitektur,

00:13:52: ob du das jetzt aufteilst in ein Dev-Ex- und ein Plattform-Team,

00:13:56: also quasi ein Team, was sehr stark diesen Metrikenfokus hat,

00:14:00: und diese Handlungsfelder identifiziert und ein anderes Team,

00:14:05: was dann die Handlungsfelder bearbeitet.

00:14:08: Und bei uns ist es aber so, dass beides in einem Team ist,

00:14:11: also nicht ein dediziertes Plattform-Engineering-Team,

00:14:15: sondern wir lösen dann manche der Probleme innerhalb des Dev-Ex-Teams,

00:14:19: also vor allem, wenn es um interne Tools, Services geht,

00:14:22: alles, was so Helfer-Line sind für den Entwickleralltag.

00:14:26: Und andere Themen bearbeiten wir dann halt in einem SE-Team

00:14:30: oder in einem anderen Team, was auch Teil der Plattform.

00:14:34: Also, das Plattformbereich ist so.

00:14:37: Mhm. Ja, verstehe, das klingt cool, ja.

00:14:43: Ähm, ja, wie sind wir jetzt dahin gekommen?

00:14:48: Wir haben es abgegrenzt.

00:14:50: Also, wir haben versucht, zu formulieren, was eigentlich die Weller-Per-Experience ist.

00:14:54: Übrigens, wenn das jetzt alles irgendwie zu hochdrabend und zu komplex war,

00:14:58: ich weiß nicht, ob ich dir die Adentrote schon mal erzählt habe,

00:15:01: aber für das Internet noch mal die Wiederholung.

00:15:04: Ich war vor einigen Jahren mal im Fitnessstudio.

00:15:06: Inzwischen gehe ich da nicht mehr hin, aber das hat andere Gründe.

00:15:09: Und dann habe ich versucht, meinem damaligen Trainer,

00:15:12: während ich schwitzend auf der Bank lag, zu erklären,

00:15:14: was ich eigentlich beruflich mache.

00:15:16: Und dann habe ich in 10 Minuten zugeschwafelt,

00:15:18: so wie jetzt gerade eben dich auch, und am Ende hat er so genickt und meinte,

00:15:21: "Ah ja, du machst, dass es flutscht."

00:15:23: Und dann habe ich gesagt, ja, genau, so hätte man es auch sagen können.

00:15:27: Ach ja, das stimmt, ja.

00:15:29: Also, das ist im Grunde die Quintessenz,

00:15:30: wir wollen, dass es für die Entwicklerinnen flutscht.

00:15:33: Aber wie geht ihr denn davor?

00:15:36: Also, ich meine, wie habt ihr, du hast schon mal gesagt,

00:15:42: na ja, wir sind wie ein Produktteam,

00:15:47: weil ich bin jetzt ja im Produktteam tätig,

00:15:50: meine Kunden sind die Kunden.

00:15:53: Ja.

00:15:55: Also, ja, und Stakeholder.

00:15:56: Deine Kunden sind die Kunden, genau, die richtigen Kunden.

00:15:58: Ja, also die Kunden, die hoffen, die Geld zahlen.

00:16:01: Aber natürlich auch ein anderes Stakeholder,

00:16:03: da sollte man immer als Kunden betrachten.

00:16:06: Ja.

00:16:07: Also, wie, wo fängt für dich denn jetzt so ein Use-Case an?

00:16:13: Also, wo kriegst du eine Anforderung her?

00:16:18: Wo fängt das bei dir mit dem Messen an,

00:16:22: gehst du hin und sagst,

00:16:23: "Wow, da könnte ich mal irgendwie eine Messprobe reinsetzen

00:16:27: und mal gucken, was passiert, ich habe so eine Theorie."

00:16:30: Oder sagst du, der Holger kommt zu dir ein und sagt,

00:16:33: "Es ist mal wieder alles Scheiße, alles ist langsam und doof."

00:16:36: Und dann kommt der Uhrser und sagt, Holger, easy, ich mach das schon.

00:16:41: Also, ganz klar beides.

00:16:42: Ja, ja.

00:16:43: Also, erst mal ist es ja so,

00:16:45: dass wir nicht völlig willkürlich irgendwelche Dinge messen,

00:16:48: sondern uns von Forschung und natürlich auch dem,

00:16:55: was andere Unternehmen tun, inspirieren lassen.

00:16:59: ... und da gibt es jetzt diverse Frameworks, die sich ...

00:17:03: damit beschäftigen, wie man jetzt geeignete Metriken festlegt für Developer Experience,

00:17:10: immer mit dem Gedanken, wenn du diese Dinge, nicht wenn du diese Dinge misst, wenn du in

00:17:14: diesen Dingen gut bist, dann ist es wahrscheinlich, dass du auch gute Dinge erreichst. Also,

00:17:19: ein Beispiel wäre zu einem Freund über Dora geredet, dass das sehr stark auch kommuniziert

00:17:26: in der Forschung. Wenn du in diesen vier Keymetrics gut bist, dann hast du eine sehr hohe Wahrscheinlichkeit

00:17:33: Organizational Success und Well-Being zu erreichen. Und so ist es aber bei anderen Metric-Frameworks.

00:17:39: Ganz konkret gibt es da die sogenannten DX Core 4, relativ neu. Es gibt das Space Framework, es

00:17:48: gibt das DX Framework, etc. Space habe ich schon mal irgendwo gehört. Das ist auch von, ich weiß es nicht.

00:17:54: Das ist auch von DX und Nicole Fostern. Ich weiß gerade nicht, wem noch mitentwickelt. Alles gerade nicht wichtig für meine eigentlich Aussage.

00:18:07: Jedenfalls gibt es Frameworks, die dir sagen, in diese Themen solltest du mal reingucken. Da steht jetzt nicht,

00:18:14: in der Regel nicht drin, miss exakt diese fünf Dinge, sondern da steht drin zum Beispiel, schau dir mal näher an,

00:18:20: wie es eigentlich in deinem Unternehmen aussieht, mit Loosly Couple Teams. Und dann kannst du dir natürlich

00:18:27: weitere Theorie anlesen und drei Metriken aus den Fingern saugen, wie du jetzt vermisst, ob du gut oder schlecht bist

00:18:36: im Thema Loosly Couple Teams. Aber das ist auf jeden Fall die Art und Weise, wie wir zu einem Teil unserer Metriken kommen.

00:18:46: Ein anderes Thema ist aber, wenn wir schon wissen, dass wir ein Problem haben, dann werden wir ja blöd, wenn wir es ignorieren würden.

00:18:53: Wir müssen nur irgendwie rausfinden, ist das ein Einzelfall? Also hat jetzt nur der Holger irgendwie Pech gehabt heute?

00:19:00: Oder haben wir ein strukturelles Problem, haben wir ein Problem in einem Team, wem müssen wir wie helfen,

00:19:08: um etwas besser zu machen und natürlich Frage der Priorisierung, wie signifikant ist dieses Problem.

00:19:14: Das ist etwas, was man oft nur abschätzen kann, natürlich. Aber du kannst nicht alle Probleme lösen, du kannst nicht jedem helfen.

00:19:21: Woher weißt du, dass wir, ich mache R-Quotes, woher weißt du, dass wir ein Problem haben?

00:19:27: Na ja, weil es mir jemand sagt. Entweder weil es mir jemand direkt sagt oder weil es so offensichtlich ist, dass du es nicht ignorieren kannst.

00:19:35: Ein gutes Beispiel wäre, jedes Unternehmen, ich stelle jetzt einfach mal die These in den Raum, jedes Softwareunternehmen, weiß, ob es eher gut oder eher schlecht im Bereich Softwarequalität ist.

00:19:51: Also wahrscheinlich kannst du keine Zahl dahinter schreiben, aber die Leute werden dir schon eher sagen, ja wir haben kein Problem mit Qualität oder sie werden dir sagen,

00:20:03: ja wenn wir ein Release gemacht haben, dann machen wir erst mal fünf Wochen Backfest.

00:20:06: Ja, ja, ja. Die Aussage, da muss ich erst mal kontroversieren, je nachdem, wie ihn du fragst.

00:20:13: Ja, ja, wahrscheinlich ja doch, da kann man schon eine Aussage zu, ja, doch, doch, doch.

00:20:21: Wenn du auf der Ebene denkst, dann hast du ja schon ein Fokusthema.

00:20:25: Also wenn du jetzt in einem Unternehmen bist, wo Qualität gerade ein Problem ist, dann wird wahrscheinlich auch Management irgendwann sagen,

00:20:32: liebe Leute, es wäre gut, wenn wir da mal besser würden und entsprechend arbeitest du in diese Richtung und entwickelst dann jetzt wieder diese Produktdenke, erarbeitest dann Produkte, die diesen Bedarf adressieren.

00:20:48: Naja, und dann um dieses Produktdenken weiter zu spinnen, unsere Kunden sind dann natürlich die Engineers und wir versuchen, deren Leben leichter zu machen und deren Alltag zum Flutschen zu bringen.

00:21:06: Das ist immer mit der Idee dahinter, dass wir das gesamte Engineering so stark entlasten können, dass es die Existenz unseres Teams rechtfertigt.

00:21:20: So wird ein Shoot raus.

00:21:24: Was ist die Existenz unseres Teams rechtfertigt?

00:21:28: Naja, wenn wir jetzt irgendwie, sagen wir mal, wir hätten zehn Entwickler.

00:21:32: Und wir arbeiten jetzt irgendwie einen Monat zu fünf im DevX-Team daran, den Entwickler zu helfen und sparen dann zwei Wochen Arbeitszeit ein.

00:21:48: Und dann haben wir einen Monat investiert, um zwei Wochen Arbeitszeit zu sparen.

00:21:53: Keine so gute Kosten-Nutzen-Rechnung, natürlich hast du die zwei Wochen dauerhaft gespart, dann kannst du noch mal nachdenken, ob es nicht doch rentiert.

00:22:00: Aber darum geht es, also musst du irgendwann einen Strich drunter machen können und sagen, die Zeit, die wir jetzt investiert haben, die hat sich rentiert, weil wir die Arbeit der anderen so stark vereinfacht haben.

00:22:14: Eine Tese, das ist jetzt auch eine wild zugespitzte Tese, letztendlich ist es dann deine Aufgabe oder die Aufgabe deines Teams, sich selber abzuschaffen?

00:22:26: Würde ich nicht unterstreichen, also weil das würde ja, dann würde die Tese ja sein, es gibt, also A) es gibt irgendwann nix mehr zu verbessern und B) wenn wir einen gewissen Zustand erreicht haben, dann kann es nicht mehr schlechter werden.

00:22:45: Ja, okay. Ja, guter Punkt. Das zielt jetzt eher darauf hin, irgendwann ist ein Grenznutzen erreicht, der...

00:22:53: Ja, wahrscheinlich. Aber ja, du hast vollkommen recht, das erodiert.

00:22:58: Genau, und erfahrungsgemäß kommst du an den Punkt nicht.

00:23:02: Ja, auch das ist, deswegen, das war die Spritzung an der Stelle.

00:23:06: Genau, das wäre so ein Moodshot-Goal irgendwie, aber wäre ich fein mit, ja, also wenn wir irgendwann an den Punkt kämen, wo wir wirklich ernsthaft sagen, wir können es nicht mehr wirklich besser machen,

00:23:20: dann müssen wir auch uns dieser Aussage stellen und müssen sagen, gut, dann gibt es einfach keinen Sinn mehr, ein so und so viel köpfiges Reflex-Team zu haben.

00:23:31: Vielleicht reduziert man es dann erstmal nur oder so, aber das ist so hypothetisch und etwas womit ich nicht ernsthaft rechne.

00:23:42: Wilde These, wir haben, ich weiß nicht, ob wir das on air oder auf air gemacht haben, wir haben über cross-functional Teams geredet.

00:23:51: Ja, ich weiß, es gibt Plattform-Teams und Streamline-Teams, aber was hältst du von der These?

00:24:01: Ich weiß noch gar nicht selber, was ich von der These halte, aber ich hause einfach mal raus.

00:24:05: Wenn wir cross-functional Teams hätten, wäre es auch eine gute Idee, dass die These Developer Experience Engineers in den einzelnen Teams zu haben.

00:24:20: Das skaliert halt nur bis zu einem gewissen Punkt.

00:24:23: Also es hängt sehr stark davon ab, welche Arbeit diese DEFX Engineers dann machen.

00:24:31: Gegen Beispiel haben wir auch gerade drüber geredet, wo das sehr gut funktioniert ist zum Beispiel SRE.

00:24:37: Wenn du einen SRE hast in einem Team, dann kann der sich um den Betrieb des jeweiligen Produktes des Teams kümmern, das skaliert ganz gut.

00:24:44: Wenn du das mit DEFX machst, dann verlierst du so ein bisschen den Skalierungsfaktor, wo du als Produktteam DEFX eine Software-Lösung entwickeln kannst.

00:24:57: Das geht aber nicht, wenn deine Leute über N-Teams verteilt sind, weil die dann weniger oder gar nicht zusammenarbeiten können und jeweils nur ihren locales Optimum finden und nicht das Optimum für das ganze Unternehmen.

00:25:17: Viele Themen, die wir bearbeiten jetzt im Kontext DEFX, beschäftigen sich mit Standardisierungen, mit Werkzeugen, von denen alle profitieren und adressieren eben nicht nur einen Team.

00:25:35: Deswegen will ich nicht pauschal sagen, dass es keine Gründe dafür geben kann, aber wahrscheinlich ist es in der Regel nicht die beste Idee.

00:25:47: Haben wir schon, möchten wir noch über die vier Buchstaben reden oder ist das eine eigene Folge?

00:25:57: Oh Gott, die vier Buchstaben?

00:25:59: Und wir reden von ABBA.

00:26:01: Natürlich reden wir von ABBA.

00:26:03: Nein, ich glaube schon, dass es eine eigene Folge wird. Die Frage ist, was willst du über die vier Buchstaben jetzt gerade reden und was davon können wir in eine eigene Folge ausladen?

00:26:17: Vielleicht machen wir so ein bisschen ein Spoiler für eine eigene Folge.

00:26:21: Ich hätte wirklich einfach nochmal, es ist für dich ja, zumindest habe ich das so verstanden, einen Kernbaustein, deine Arbeit, ich würde wahrscheinlich einfach nochmal über reden, was ist das denn überhaupt?

00:26:40: Auch wenn es schon 20 mal gesagt wurde, in drei Minuten, was ist das und warum ist das gut?

00:26:49: Ja, okay.

00:26:51: Und welches ist dein Lieblingsalbum?

00:26:55: Dafür bin ich zu jung, Folge.

00:26:58: Qualitäten ist übrigens.

00:27:05: Die vier Buchstaben, Dora, ist die DEF Ops Research and Assessment, nichts zu tun mit der anderen Dora, von der gerade viel geredet wird.

00:27:16: Ich versuche auch immer bei Dora, es gibt ja so gerne Akronüme, wo die einzelnen Bestandler, wir reden ja auch von vier Metriken, dass die Metriken irgendwas mit dem mit Dora zu tun haben, haben sie aber gar nicht?

00:27:28: Nein, haben sie nicht, genau.

00:27:30: Da greifst du jetzt aber schon vor.

00:27:32: Entschuldigung, natürlich.

00:27:34: Es gibt so genannte Four Keymetrics, die nennt man auch gerne die Dora-Metriken und Dora ist eben kein Akronüm für diese vier Metriken.

00:27:45: Und Dora, wie der Name schon sagt, dreht sich um DEF Ops.

00:27:51: Also es geht nur um einen bestimmten Teil der, ich sag jetzt mal Developer Experience, es geht eigentlich bei denen gar nicht um Developer Experience, sondern um DEF Ops, aber anderes Thema.

00:28:02: Es geht also um die Delivery, also wie kriege ich Software gut zum Kunden und idealerweise auch in einer guten Qualität zum Kunden.

00:28:12: Das heißt, es gibt diese vier Metriken, zwei davon haben den Focus Speed, zwei andere haben den Focus Qualität.

00:28:18: Und die These ist, wenn sich beides die Waage hält und beides relativ gut ist, dann ist das auch gut für dein Unternehmen und lässt gewisse Rückschlüsse zu.

00:28:27: Das heißt, es gibt eine sehr, sehr umfassende Forschung von eben der Dora zu dem Thema, wo auch empirisch belegt ist, dass diese vier Keymetrics eine Vorhersage zulassen auf Unternehmenserfolg und Well-Being.

00:28:50: Well-Being, ja, ich hab gerade nach dem deutschen Wort für Well-Being gesucht, aber lass uns einfach Well-Being sagen.

00:28:57: Wohlbefinden der Mitarbeitenden, genau, in der Softwareentwicklung.

00:29:01: Und damit es jetzt nicht so völlig aus der Luft gegriffen wirkt, vielleicht so ein paar Beispiele.

00:29:07: Also einerseits ist das, glaube ich, relativ leicht nachvollziehbar, wenn man in der Lage ist, schnell auf sich änderte Marktanforderungen zu reagieren und Features schnell zu den Kunden zu bringen.

00:29:17: Dann ist es wahrscheinlicher, dass das Unternehmen erfolgreich ist, dass so die eine Seite.

00:29:23: Und natürlich, wenn man auch qualitativ hochwertige Features ausliefert, ist es wahrscheinlicher, dass das Unternehmen erfolgreich ist.

00:29:29: Das andere Thema ist, wenn man kleine Arbeitspakete macht und das so ein bisschen ein Subset davon, dann hat man in höhere Wahrscheinlichkeit, dass Releases nicht in totalem Chaos enden und stabil bleiben.

00:29:49: Entsprechend geht es den Menschen besser, weil sie entspannter sind, weil sie Releases zum Beispiel auch in ihrem Arbeitsalltag machen können und nicht ein Wochenende dafür blocken müssen.

00:29:58: So ein Thema Work-Life Balance spielt da eine Rolle. Und so hängt das alles zusammen.

00:30:03: Und es gibt ein sehr lesenswertes Buch dazu, wahrscheinlich kennt es viele der Zuhörenden schon.

00:30:08: Das heißt Accelerate und Accelerate packen wir die Show Notes.

00:30:16: Genau, legst so ein bisschen den wissenschaftlichen Kontext unter dieses Thema.

00:30:23: Und genau, entstanden ist es, vielleicht das noch erwähnenswert, es gibt einen jährlichen Report dazu, heute heißt der Dora Report.

00:30:34: Und dieses Buch Accelerate erläutert eben wissenschaftlich, was hinter diesem Dora Report steckt.

00:30:44: Der Dora Report legt immer jedes Jahr so ein bisschen an spezifischen Fokus, aber schaut quasi auf den Status von DevOps in der Industrie, versucht es zu vergleichen über die Industrie hinweg.

00:30:59: Genau, und wir hängen das jetzt mit uns zusammen. Ich sag das schon, das ist so ein bisschen subset von dem, was wir uns auch anschauen.

00:31:06: Und es ist eben Teil der Developer Experience, weil wir sagen, wir wollen DevOps leben.

00:31:14: So ein bisschen dieser "you build it, you run it" Gedanke, wenn ein Team etwas baut, dann ist es auch für den Betrieb zuständig.

00:31:20: Und entsprechend ist es Teil der Developer Experience, wie gut die Delivery Performance ist.

00:31:27: Und das ist etwas, was wir jetzt gerade an Knüpfung an ganz vorhin, was wir gerade optimieren wollen.

00:31:35: Also wir wollen diese Delivery Performance verbessern, schauen es deswegen gerade sehr konkret diese Dora-Metriken an,

00:31:40: aber nicht nur die Dora-Metriken, sondern auch die Capabilities, die Dora-Metriken umfassen.

00:31:47: Aber das klären wir dann bei einer eigenen Folge.

00:31:50: Das waren jetzt mehr als drei Minuten, oder?

00:31:52: Ja, das waren ungefähr drei Minuten. Ja, cool, vielen Dank.

00:31:57: Finde ich total spannend. Ich fände es, ja, also wir müssen auf jeden Fall noch mal ein bisschen reindrillen.

00:32:03: Ich finde besonders, das sind den Punkt spannend, der war mir glaube ich gar nicht so richtig explizit klar,

00:32:08: dass dieser Well-Being-Punkt da drin ist und wieder da zusammenhängt, da kann man fast eine eigene Folge noch mal zu machen.

00:32:13: Ich weiß noch nicht, wie und in welcher Form, aber so ein, aber das Thema Developer Well-Being

00:32:21: fände ich mal einen ganz interessanten Aspekt.

00:32:25: Ich weiß noch nicht in welcher Form, aber vielleicht hätten wir da mal einen interessanten Spin.

00:32:30: Also so ein bisschen, um da vorzugreifen, es gibt auch immer wieder die gegenläufige These,

00:32:35: wo man sagt, glückliche oder zufriedene Entwickler sind viel wahrscheinlicher auch effiziente und effektive Entwickler.

00:32:45: Und dann ist das natürlich ein bisschen ein Zirkelschluss, aber das finde ich auch eine spannende Betrachtung,

00:32:52: dass du quasi sagst, erstmal sorge ich dafür, dass es den Leuten gut geht und wenn es denen gut geht,

00:32:57: dann werden sie wahrscheinlich auch ihre Arbeit besser machen wollen und wenn das ihnen ermöglicht, auch können.

00:33:04: Gut, machen wir einen Strich drunter.

00:33:08: Machen wir einen Strich drunter, ja.

00:33:09: Ich habe keine Ahnung, wie viel Zeit wir schon reden.

00:33:11: Wir sind bei 35 minus X, keine Ahnung.

00:33:15: Schöne runde Zahl.

00:33:16: Schöne runde Zahl, ja.

00:33:17: Ich sage mal, danke schön, das hat sehr viel Spaß gemacht.

00:33:19: Ich bedanke mich.

00:33:20: Und ja Leute, wenn ihr noch mehr Fragen habt, besonders an US, an über das Thema Developer Experience Engineering,

00:33:29: über Developer Experience, schreibt es unten in die Kommentare, die wir noch nicht haben.

00:33:35: Schreibt uns einfach, ihr wisst, wie ihr uns erreichen könnt und ja, in diesem Sinne, so schicken wir es nach Hause.

00:33:43: So machen wir das.

00:33:44: Vielen, vielen Dank und auf Wiederhören.

00:33:46: Bis dann, tschüss.